1. Field of the Invention
The present invention relates in general to storage systems, and particularly to, systems and methods for managing a virtual tape library domain.
2. Description of the Related Art
A virtual tape library (VTL) typically provides a host with a high-speed tape library by using, for example, disks. In general, the host uses the tape library as follows:
1.) The host inserts a tape volume (hereinafter, referred to as a “volume”) into the tape library. The volume is identified by a volume serial number (“VOLSER”) and the inserted volume is categorized under a category named “insert” category. A category is one of the volume attributes and is necessarily defined for each volume to represent the state and usage of the volume at a particular time;
2.) The host transfers the volume in the insert category to a “scratch” category. The scratch category is used to store blank and/or reusable tapes;
3.) The host requests the mount of a volume. The tape library mounts the requested volume and provides the host with the volume. The host requests the mount by specifying the VOLSER and requesting the mount of a specific volume (specific mount) or by specifying a category and requesting any volume in the category (category mount). In the case where new data is written starting at the beginning of the volume, generally the scratch category is specified and a category mount operation is performed (hereinafter, referred to as a “scratch mount”);
4.) The host transfers the mounted volume into a “private” category and performs an input/output (I/O) operation;
5.) After the completion of the I/O operation, the host requests a “de-mount” of the volume; and
6.) With regard to a volume no longer required among the volumes in the private category, the host transfers the volume to the scratch category. Basically, the data in the volume transferred to the scratch category is no longer guaranteed and may be erased at this point in time such that the volume is reusable. The volume in the scratch category is provided to the host when the host later requests the mount of the volume.
In the case where no volumes are left in the scratch category, the tape library recognizes that there is no available blank or reusable tape. If the host requests a scratch mount in such a situation, the mount request fails.
The VTL performs the above functions utilizing storage disks. There are many advantages to utilizing storage disks compared to a physical tape library, particularly, in that the VTL is able to respond to a scratch mount request at high speed. The VTL is able to quickly respond to the host because a logical volume is prepared on the disks, instead of actually mounting a physical tape.
Moreover, the VTL does not typically immediately erase the data in the volume once the volume is transferred to the scratch category so that a user is able to restore the data of a volume that the user mistakenly transferred to the scratch category. Instead, the data is left in tact for a predetermined amount of time (e.g., 24 hours) before the data is erased. In this regard, a volume which is in the scratch category and whose data is not erased yet is referred to as a “scratch unerased” volume and a volume whose data was completely erased after a lapse of the predetermined amount of time is referred to as a “scratch erased” volume.
In addition, many VTLs support clustering of multiple VTLs. An object of clustering VTLs is to increase the number of virtual tape drives and the disk capacity, and to implement higher availability and disaster recovery solutions by data replication. In general, VTLs are connected to each other via an Internet Protocol (IP) network or the like, and appear as a single virtual tape library to the host. Here, the entire clustering configuration is referred to as a “VTL domain” and each of the VTLs constituting the VTL domain is referred to as a “VTL node.”
When the host performs an insertion or mounting operation in the clustering configuration, a request command from the host is received by a VTL node to which the host is physically connected. Thereafter, the VTL nodes communicate with each other to have consistency within the VTL domain and to return a reply to the host.
In the VTL clustering configuration, it is also possible for two VTL nodes to be connected to one host, and the host operates such that the host individually issues mount requests to each of the VTL nodes. In such a case, a scratch category common to the two VTL nodes is generally used.
During operation, conventional VTL nodes are expected to comply with a mount request from the host by operating as follows:
1.) The VTL nodes communicate with each other to check how many volumes in the scratch category (e.g., scratch unerased volumes and scratch erased volumes) exist in the VTL domain; and
2.) The VTL node selects a volume, which is erased at the earliest possible time, among the scratch erased volumes and provides the volume to the host. If there are no scratch erased volumes in the entire VTL domain, the VTL node selects a volume, which is transferred to the scratch category at the earliest possible time, among the scratch unerased volumes and provide the volume to the host.
If these operations are performed every time the host requests the mount, the VTL nodes will need to communicate with each other to select a scratch volume each time the host requests the mount, which sacrifices mount performance, which is a primary goal of VTL nodes. One conventional technique to overcome the need for the VTL nodes to communicate with each other every time the host requests a mount provides a method that determines ahead of time which volumes are going to be managed by which VTL node. That is, for each volume, a VTL node is designated as the “owner” of the volume, which ownership is transferrable between VTL nodes. The volume owner VTL node has the exclusive access to the user data and the metadata of the volume. When a VTL node needs to mount a volume and the node is not the current owner of the volume, the VTL node first acquires ownership of the volume in the VTL domain and becomes the new owner of the volume.
All of the volumes, including the volumes transferred to the scratch category, have their owner node defined at all the times. Specifically, when the host issues a scratch mount request to a VTL node, the VTL node selects the earliest volume from the volumes that are in the scratch category and whose owner is the VTL node, and provides the earliest volume to the host. In this regard, even if there is no scratch erased volume and the earliest volume is a scratch unerased volume, the VTL node erases data in the scratch unerased volume at that time and then provides the volume to the host. Only in the case where the VTL node has no volume that is in the scratch category and whose owner is the VTL node does the VTL node communicate with other VTL nodes in the VTL domain. Here, the VTL node selects the earliest volume in the VTL domain, transfers the ownership of the earliest volume to itself, and then provides the earliest volume to the host.
While this method optimizes the scratch mount performance by minimizing the communication between VTL nodes, the elimination of communication between VTL nodes may cause other inefficiencies. The following describes at least some of the inefficiencies experienced when multiple VTL nodes do not communicate with one another:
1.) In a clustering configuration, which is composed of two or more nodes (e.g., a VTL node 0 and VTL node 1), there is a possibility that there may be a significant difference between the number of scratch volumes for which VTL node 0 has the ownership of and the number of scratch volumes for which the VTL node 1 has the ownership of. For example, VTL node 0 may own many scratch volumes and VTL node 1 may own only a few scratch volumes;
2.) In this situation, the rate at which the host transfers a volume to the scratch category may be about the same as the rate at which the host issues a scratch mount request to the VTL nodes;
3.) In this case, there should be enough scratch unerased volumes and scratch erased volumes whose owner is VTL node 0. Here, upon receiving a mount request from the host, the VTL node 0 returns the earliest volume among the scratch erased volumes whose owner is the VTL node 0 to the host. On the other hand, however, there are not many scratch volumes whose owner is the VTL node 1 and it is possible that no scratch erased volumes whose owner is the VTL node 1 exist yet. Therefore, upon receiving a scratch mount request from the host to VTL node 1, VTL node 1 will need to erase a scratch unerased volume whose owner is VTL node 1 at that moment and provide the erased volume to the host, even though there still remains a scratch erased volume whose owner is VTL node 0; and
4.) In this situation, a volume whose owner is VTL node 1 may possibly be prematurely erased immediately after the host transfers the volume to the scratch category. In the case where the user transfers the volume to the scratch category by an operating error, the data will be completely lost and cannot be restored.